home *** CD-ROM | disk | FTP | other *** search
-
- Network Working Group R. Braden
- Request for Comments: 831 University College London
- December 1982
-
-
-
-
-
-
-
-
-
- Backup Access to the European Side of SATNET
-
-
-
-
- Robert Braden
-
-
-
-
-
-
- DISCUSSION
-
- The purpose of this RFC is to focus discussion on a
- particular Internet problem: a backup path for software
- maintenance of the European sector of the Internet, for
- use when SATNET is partitioned. We propose a
- mechanism, based upon the Source Routing option of IP,
- to reach European Internet sites via the VAN Gateway
- and UCL.
-
- This proposal is not intended as a standard at this
- time.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Network Working Group R. Braden
- Request for Comments: 831 University College London
- December 1982
-
-
-
- 1. Introduction
-
- During several previous SATNET meetings, it has been
- observed that it would be useful for BBN to be able to
- access the European side of SATNET indirectly via the VAN
- Gateway, when direct SATNET connectivity has been lost.
- This short paper proposes a possible approach to such
- "backup" access, using the source routing option of IP.
-
- Figure 1 illustrates the problem we wish to solve. The US
- host H is used for diagnosis and control of the SATNET
- SIMP's S1 and S2 as well as the gateways B and G and the UCL
- TAC (not shown, but connected to G).
-
-
- SATNET
- (partitioned)
- ARPANET/SATNET __ __ UCL
- Gateway Simp ( \ \ ) Simp Gateway
- ____ ___( / / )____ ____
- | B |__| S1 | \ \ | S2 |________| G |_____ rsre
- |____| |____| / / |____| |____|
- | ( \ \ ) |
- | (__ / /__) _______|____
- ________|____ ( )
- ( ) ( )
- ( ARPANET ) ( UCL NET )
- ( ) ( )
- (_____________) ( )
- | | (_____________)
- __|_ | VAN/ .
- | H | | Public Data Nets .
- |____| | _____________ .
- Diagnostic | ( ) .
- Host __|__ ( VANNET ) _.___
- | VAN |* * (* * * * * * * * *)* * * * | |
- | gw------(--- IP Tunnel -----)--------| U |
- |_____|* * (* * * * * * * * *)* * * |_____|
- VAN ( )
- Gateway (_____________)
-
-
- Figure 1. US/UK Connectivity with Partitioned SATNET
-
-
-
-
-
-
-
-
- RFC 831 - 1 - [Braden]
-
- Network Working Group R. Braden
- Request for Comments: 831 University College London
- December 1982
-
-
-
- VANgw is the VAN Gateway which encapsulates IP datagrams in
- X25 packets for transmission over VAN/PTT virtual circuits.
- The collection of these paths, called "IP tunnels" by UCL,
- is addressed from the Internet as a distinct network,
- VANNET.
-
- U is a UCL host, the Terminal Protocol Converter, which
- provides a path to UK X25 networks. However, to the Internet
- world U looks like a host on VANNET, so the path from U to
- UCLNET (shown dotted) does not appear to exist.
-
- Now suppose SATNET is partitioned between S1 and S2. Then
- we wish host H to be able to exchange IP datagrams with S2
- via the "back door" path:
-
- H - Internet - VANgw - VANNET - U - UCLNET - G - S2
-
- There are some important rules in this game, however.
-
- (1) U may only be a host, not a gateway.
-
- This is because we do not want the Internet to route
- ALL its traffic (e.g. rsre traffic and UCL traffic
- that is required to use SATNET) via the IP Tunnel.
- So the VAN Gateway (VANgw) must not discover it can
- get to UCLNET through U.
-
- (2) To implement the back door path to S2, we are
- willing to have some special code in H and/or in U,
- but not in G, S2, or VANgw.
-
- Note: Jack Haverty is allowed to violate this
- assumption, though we doubt that he will want to.
- But we must stick to it.
-
- Given these constraints, we claim that the only possible
- solution is to "mung" the headers of IP datagrams at UCL.
- Thus, when SATNET is partitioned:
-
- (1) The IP addresses of S2, G, and the UCL TAC are
- unreachable from all US gateways. Therefore, if H
- sends a packet addressed to one of these
- destinations, it will be discarded and an ICMP
- unreachable message returned.
-
-
-
-
-
-
-
- RFC 831 - 2 - [Braden]
-
- Network Working Group R. Braden
- Request for Comments: 831 University College London
- December 1982
-
-
-
- (2) Similarly, the IP address of H is unreachable from
- the UK side. Hence, if the XNET debugger in a UK
- host emits a return packet addressed to H, that
- packet will be dropped.
-
- Therefore, the destination address of each packet from H
- must be changed in order to reach the UCL side of SATNET (S2
- or G), and the source address of each of these packets must
- be changed so that return packets can reach H. For this
- purpose, we introduce the Munger host M (see Figure 2).
-
- SATNET
- (partitioned)
- BBN __ __ UCL
- Gateway Simp ( \ \ ) Simp Gateway
- ____ ___( / / )____ ____
- | B |__| S1 | \ \ | S2 |________| G |_____ rsre
- |____| |____| / / |____| |____|
- | ( \ \ ) |
- | (__ / /__) _______|____
- ________|____ ( )
- ( ) ( )
- ( ARPANET ) ( UCL NET )
- ( ) ( )
- (_____________) ( )
- | | (_____________)
- __|_ | |
- | H | | Public Data Nets |
- |____| | _______________ _|___
- Diagnostic | ( ) | M1 |
- Host __|__ ( ) |:::::|
- | VAN |* * (* * * * * * * * * *) * * |:::::|
- | gw------(--- IP Tunnel -----)------------| M2 |
- |_____|* * (* * * * * * * * * *) * * |_____|
- VAN ( VANNET ) M
- Gateway (_______________) "Header
- Munger"
-
- Figure 2. Introduction of Header Munger at UCL
-
-
- Host "M" (M1/M2) is mulit-homed, appearing as host M2 on
- VANNET and as host M1 on UCLNET. Like host U (shown in
- Figure 1), host M2 is the end of an IP Tunnel which
- communicates with VANgw over an X25 virtual call.
-
-
-
-
- RFC 831 - 3 - [Braden]
-
-
-
- Network Working Group R. Braden
- Request for Comments: 831 University College London
- December 1982
-
-
-
- Suppose for example that host H desiollege London
- December 1982
-
-
-
- Suppose for example that host H desires to reach the XNET
- debugger in the SIMP S2. H must send its packets with
- destination address M1; these will be routed to M1 via VANgw
- and the IP Tunnel. Host M will change the headers of these
- datagrams to contain source address M1 and destination S2.
- S2 will return packets to M1, and M1 will change them back
- to M2->H packets and launch them back through the VANNET to
- H.
-
- How does M know how to change the headers?
-
- (1) M could respond to a range of M1 and M2 addresses,
- and have a fixed table of correspondence.
-
- (2) We propose instead to use the SOURCE ROUTING option
- in the datagrams. This assumes that H is able to
- build source-routed datagrams, and is not upset that
- the intermediate host in the route is not a gateway.
-
- If we further assume that the IP layers in G and S2
- can handle source and return routes, then the task
- is simple. M must contain the source routing
- algorithm of a gateway, but otherwise act as two
- hosts (no routing updates, etc).
-
- (3) Although G supports source routing, S2 and the TAC
- may not. In that case, S2 and the TAC will not be
- able to recognise the return route in a received
- packet and use it as a source route in packets sent
- in reply.
-
- This possibility calls for additional complexity in
- M, a combination of (1) and (2):
-
- * In the US -> UK direction, the Source
- Routing option would be used.
-
- * In the reverse direction (UK -> US),
- mapping of datagram addresses would be
- controlled by a table in M.
-
-
-
-
-
-
- RFC 831 - 4 - [Braden]
-
- Network Working Group R. Braden
- Request for Comments: 831 University College London
- December 1982
-
-
-
- We suggest that M use source routing to get packets
- from H to S2, and meanwhile build a "soft state"
- table showing this mapping. When a packet comes
- from S2 without source routing, M would consult this
- soft state table to discover how to alter the
- addresses to reach H again. This would allow only
- one US host at a time to access a given SATNET host,
- but surely this is no restriction.
-
-
- In practice, M2 and U should have different IP tunnels and
- hence different DTE addresses. Since the caller pays the
- X25 charges, the IP Tunnel for U will normally be opened
- only by UCL. On the other hand, the IP Tunnel to M2 will be
- opened from the US end. Since UCL has only one PSS line,
- this requires the use of separate X25 subaddresses. The VAN
- gateway must handle 14 digit X121 addresses, as well as 12
- digit addresses.
-
-
- 2. Acknowledgment
-
- Robert Cole of UCL has made major contributions to the
- contents of this paper. In particular, he suggested the use
- of the Source Routing option.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- RFC 831 - 5 - [Braden]
-